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(57) ABSTRACT 

A special BIOS includes a program application manager 
(PAM) and a file system structure (FSS) that points to 
addresses on a mass storage device (MSD) for an application 
and at least one presentation playable by the application. The 
BIOS calls the PAM on startup, and the PAM checks for an 
application, and finding same loads and executes the appli- 
cation before loading the operating system (OS). In a 
preferred embodiment the FSS is programmable, and the 
system after OS boot is started checks MSD devices for new 
FSS parameters, and finding same loads the parameters to 
the programmable FSS of the BIOS. In some embodiments 
parameters may cause presentations and associated applica- 
tions to be accessed and executed in a rotating or serial order. 
In other embodiments the BIOS represents its own address 
space in RAM to the OS at OS boot to include the 
application, enabling the application to continue to execute 
during OS boot. In further embodiments a special driver is 
executed after OS boot to bind the application into the OS 
configuration so the application may continue to operate in 
a stable manner. 

13 Claims, 10 Drawing Sheets 




11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 1 of 10 



US 6,564,318 Bl 



101 



103 



105 




Compressed Bios 
(Flash Rom) 



8 KB Boot Block 



4KB PnP (ESCD) 



4 KB P6 Micro-code 



Code Decompresion 
& 4 KB Memory Sizing 



Compressed BIOS 



VROM-DVR 



64 KB OEM Routines 



64 KB for add-in ROM's 
SCSI, VGA, Network, 
PC Card 



F000:FFFF 

F000:E000 

F000:D000 

FOOO:C0OO 
F000:8000 
F000:0000 



E000:0000 



D000:0000 



C000:0000 



Fig. 1 



11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 2 of 10 US 6,564,318 Bl 



■107 



F000:FFFF 



F000:8000- 



F000:0000 



£000:0000 



Decompressed BIOS 
(Shadow RAM) 



8 KB IBM Compatible Code 



24 KB Runtime 



32 KB Setup 



64 KB POST Code 
(Before Booting) 



64 KB Empty 
(After Booting) 



109 



111 



Device 


Shadowed to 


VGA 


C0000-C7FFF 


SCSI 


C8000-DFFFFF 


Network 


C8000-DFFFFF 


PC Card 


C8000-DFFFFF 



Fig. 2 



11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 3 of 10 US 6,564,318 Bl 



VROM Application 
User interface to manipulate each VROM area. SDK library 
APIs included for third-party software to call the VROM BIOS. 

VROM Driver 
Operating system-dependent module. 
Cooperates with VROM BIOS to access each VROM area. 

VROM BIOS 
VROM BIOS-layer functions 



Application Layer 



VROM Applications 
Including 

VROM SDK Library API 




Operating System 
Layer 



VROM BIOS 
Layer 



VROM 


Driver 


> 




> 


r 


VROM 


Interface 


> 






r 


VROM BIOS 



115 



117 




Fig. 3 



11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 4 of 10 US 6,564,318 Bl 



Field Offset Length Value 



Signature 


OOh 


8-bytes 


VROMBIOS 




Version 


08h 


1-byte 


lOh 




Length 


09h 


1 Word 


2Ah 




Checksum 


OBh 


1 byte 






Real Mode offset 
to entry point 


OCb 


1-word 






Real Mode segment 
to entry point 


OEh 


1-word 


FOOOh 




32-bit protected mode 
code segment base address 


lOh 


1-Dword 






Protected mode offset 
to entry point 


14h 


1-Dword 






16-bit protected mode 
code segment base address 


ISh 


1-D word 






32-bit code segment length 


ICh 


1-Dword 


128K 




16-bit code segment length 


20h 


1-Dword 


64K 




32-bit VROM segment base address 


22h 


1-Dword 






32-bit VROM data segment length 


26h 


1-Dword 


128K 















Installation Check Table 

Fig. 4 



11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 5 of 10 US 6,564,318 Bl 



Signature 


Represented as ASCII string " VROMBIOS" 


Version 


A dLD value i.e. (value 01 ion = version l.U. 


Length 


Total bytes of the entire installation structure starting from 
the signature field 


Checksum 


Adds up the bytes in the installation structure and verifies a 
valid structure 


Real Mode Interface Segment offset of the entry point 


32-bit Protected Mode Interface Code segment base address 



Field Definition Table for Fig. 4 



Fig. 5 



11/22/2003, EAST Version: 1.4.1 



U.S. Patent May 13, 2003 Sheet 6 of 10 US 6,564,318 Bl 



Function-0 Get VROM Lists 

Description: Returns VROM lists residing in flash VROM 
into List Buffer. 

Function-1 Get VROM Size 

Description: Returns VROM Size in bytes available 
to third party calling software 

Function-2 Enable/Disable VROM List 

Discription: Allows third party calling software to enable or disable 
The VROM list in the VROM Lists 

Function-3 Read in VROM Data 

Description: Read in the VROM Data of the specified VROM list 
from the VROM area 

Function-4 Add/Delete VROM Data 

Description: Allows third party calling software to add or delete 
VROM data 

Table of third party software functions 

Fig- 6 
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Table of VROM List Stucture 
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METHOD AND APPARATUS FOR 
EXECUTION OF AN APPLICATION DURING 
COMPUTER PRE-BOOT OPERATION AND 
POST-BOOT UNDER NORMAL OS 
CONTROL 

CROSS-REFERENCE TO RELATED 
DOCUMENTS 

The present invention is a continuation in part (CIP) to 
co-pending U.S. patent application Ser. No. 08/988,603, 
filed on Dec. 10, 1997, and entitled Method and Apparatus 
for Standardizing Use of Non- Volatile Memory Within a 
Bios-Rom. The prior case is incorporated herein in its 
entirety by reference. 

FIELD OF THE INVENTION 

The present invention is in the field of Basic Input Output 
System (BIOS) systems and has particular application to 
methods and apparatus including software for accessing a 
mass storage device to execute an application by utilizing 
unused flash or other non-volatile memory within a com- 
puter BIOS system chip and then continue using it after 
booting the OS. 

BACKGROUND OF THE INVENTION 

The present invention relates to system Basic Input Out- 
put Systems (BIOS). It is well-known in the computer arts 
that a BIOS program is provided, particularly for personal 
computers, to manage the intricate and critical operations of 
testing and initializing system hardware and, in general, 
preparing the computer and its connected peripherals for 
operation. Part of this procedure is widely known as a 
Power-On Self Test (POST) sequence. Beyond the POST 
procedure, the BIOS directs Boot operations, typically from 
a designated Boot device, such as a connected hard disk 
drive, and after Boot BIOS routines are accessed as needed 
to support operations such as communication between the 
connected digital devices that make up the computer system. 

In early stages of PC development a relatively small, 
non-volatile, read-only memory (ROM) chip was more than 
adequate for system BIOS, and the relatively slow access to 
ROM was also adequate. As PC technology has developed 
to much faster CPUs and a wide range of ever more 
powerful and sophisticated peripheral devices, BIOS devel- 
opment has been forced to keep pace. BIOS routines have 
become much larger than early systems, and high operating 
speed has become necessary. 

As a result of system development it is now common in 
state-of-theart systems for BIOS to be compressed in a ROM 
chip, and for BIOS routines to be shadowed to system 
random-access memory (RAM) where the routines may be 
accessed and executed and much higher speeds than is 
possible running directly from ROM. 

At the same time that BIOS routines have been enhanced 
and further developed for more sophisticated and powerful 
PCs, there has been parallel development in ROM chips. 
One such development is known as Flash ROM. Flash ROM 
is non-volatile IC memory that may be erased, either as a 
whole or in specific blocks, and overwritten with new 
memory values. BIOS is now provided in high-end PCs in 
these Flash ROM chips, providing new advantages, such as 
an ability to address system bugs in the field. BIOS can 
hence be M re-flashed" in the field to provide a new version, 
for example, such as by downloading a new version from the 
Internet, and re-flashing the existing BIOS ROM with the 
new version. 
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In a related development, flash ROM chips have been 
made larger and faster, and for various reasons related to 
economy of scale it has become uneconomic to make small 
flash ROM chips. At the time of the present patent applica- 

5 tion flash ROM chips are readily available in sizes of, for 
example, 1 mega-bit, (1 Mb), and 2 and 4 Mb and larger. 
These sizes relate to the more common byte -related memory 
capacity designation by a factor of eight. A four Mb Flash 
ROM the has a code capacity of 512 kilobyte (KB). 

10 As a consequence of the availability of relatively 
inexpensive, large flash ROM chips, and the fact that com- 
pressed code is now common in BIOS, it is quite common 
at the time of the present application for system BIOS in 
Flash ROM to occupy considerably less than the total 

15 memory capacity of the chip. At the same time, because 
rapid development of new peripherals and expanded func- 
tionality of others, such as video displays, which are now 
high resolution and in color, there is a need for initialization 
of many devices at system start up, and initialization of all 

20 the devices cannot be included in the system BIOS all of the 
devices. Many such devices (VGA adapters, for example) 
therefore have BIOS functions provided by the manufactur- 
ers of the devices. 

With the use of larger ROM chips, and particularly with 

25 Flash ROM, it is now possible for original-equipment manu- 
facturers (OEMs), Value-Added Resellers (VARs) and the 
like to use extra memory capacity in a ROM chip storing 
BIOS functions for providing BIOS functions for 
peripherals, and also other routines, such as, for example, 

30 pre -boot security routines. With the present state of the art, 
however, it is necessary that a third party cooperate closely 
with a BIOS provider to add to and enhance the functionality 
of a BIOS chip; The partitioning, addressing, size, and other 
characteristics of the chip have to be known by the third 

35 party, and the structure and storage estate of the resident 
code has to be known as well. 

A system known to the inventor allows a third party to 
flash in BIOS instructions for plug-n-play devices and 

40 certain utility applications so that they may be executed 
before or during the booting of the OS. Such a convention 
described as a virtual ROM (V-ROM) BIOS may be altered 
via a third party without requiring that the editing party have 
intimate knowledge of the architecture or data mapping of 

45 the chip. This system is described in the parent application 
referenced above. 

It is desirable, in addition to flashing in certain added boot 
instruction to pre -boot operation, to be able to initiate and 
execute certain applications that would normally and con- 

50 ventionally depend upon a full loading of the OS before 
access is possible. 

What is clearly needed is a BIOS system that has a 
program installed for finding, initializing, and executing 
certain applications from a hard drive or other mass storage 

55 device (MSD) before an operating system has loaded. Such 
a program would allow such as multimedia applications to 
play in a pre-planned manner providing advertisement or 
other viewer-targeted information before the operating sys- 
tem is loaded. It would further be desirable for such a system 

60 to allow pre -boot applications to run during loading of the 
operating system, and even to be registered and integrated 
with the operating system to continue to run after the 
operating system is loaded. 

SUMMARY OF THE INVENTION 

In a preferred embodiment of the present invention a 
method for calling an application on a computer before 
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booting an operating system (OS), and continuing to execute FIG. 4 is a table illustrating the structure of a third party 

the application during OS boot is provided, the method software installation check for a VROM BIOS according to 

comprising steps of (a) including a preboot application an embodiment of the present invention. 

manager (PAM) software in a BIOS directing computer FIG. 5 is a field definition table for the fields represented 

initialization and operating system (OS) boot; (b) calling and 5 m pio. 4. 

executing the PAM upon startup prior to OS boot; (c) ' " 

checking a file system structure (FSS) in the BIOS by the FIG. 6 is a table illustrating third party software functions 

PAM for pointers to an application; (d) loading the appli- according to an embodiment of the present invention, 

cation to RAM and executing the application; (e) at OS boot, FIG. 7 is a table illustrating VROM List structure and an 

presenting the address extent of the BIOS as including the 1Q accompanying definitions table according to an embodiment 

application; and (f) continuing to execute the application of the present invention. 

during OS boot. FIG. 8 is a process flow chart illustrating process steps 

In further embodiments there is a step for calling a special according to an embodiment of the present invention, 

driver after OS boot to register the application and include piG. 9 is a process flow chart depended from the flow 

it in the OS configuration, thereby enabling the application 15 cnart 0 f FIG. 8 illustrating an application loading sequence 

to execute in a stable manner after OS boot. The PAM in according to an embodiment of the present invention, 

some applications may be a part of a configurable virtual piG 1Q fa a block diagram shov ^ ng location of progr a ms 

random access memory BIOS (VROM BIOS) implemented k a tQ memory map ^ of coqXtq]s {n ^ 

in flash memory. embodiment of the invention. 

In another aspect of the invention a computer system is 20 

provided, comprising a pre-boot application manager (PAM) DESCRIPTION OF THE PREFERRED 

in a system BIOS directing computer initialization and EMBODIMENTS 

operating system (OS) boot; a random access memory rj , j- * r *i_ 

(RAM); aid an operating system (OS). The BIOS is shad- In a tffl ^ of '^r' T ™ " 

owed to RAM at power™ or reset, .he PAM executes to 2S »3»tcm BIOS .s provided in flash ROM together with i a 

check a file system structure (FSS) in the BIOS for a pointer ""^ dnver ^ated with the BIOS as a mechanism for 

to a pre-boot application, upon Ending a pre-boot applica- ? n0 ™f^ mg : ft'.™** t WA'X' 

tion the application is loaded to RAM and executed, and at «*• . ? ? of i n ? nt,0 u n 15 , not Umi t0 F,ash R0 1 M ' 

OS boot, the BIOS represents the BIOS space in RAM to the but be a PP hed l ° °' h « ' v f? of reprogrammable 

OS as including the space of the application. 30 memory. Flash ROM « considered by the 

? j- . * *u * .u * -i inventor to be a good choice for illustrating the several 

In some embodiments of the system there is a special ^ ^ mQg * ■ ^ fa a 

dnyer called after OS boo. to register the apphcaUon and * embo diment of the invention will be provided in 

include it m the OS configuration, thereby enabling the ROM 
application to execute in a stable manner after OS boot. The 

PAM may be a part of a configurable virtual random access 35 In mis specification the BIOS is named a Virtual ROM 
memory BIOS (VROM BIOS) implemented in flash BIOS (VROM BIOS) and the unique driver which is part of 
memo J, the BIOS is termed the VROM-DVR. Given a flash-chip- 
In yet another aspect a basic inputoutput system (BIOS) VROM B } 0 * P ro ? u ^ a B f I0S manufacturer 
is provided, comprising a BIOS code portion for initializing accordm S t0 an t^ 0 ^ 0 preSent ^yention, havu^ 
a computer system and loading an operating system (OS); 40 ™ instance of VROM-DVR, a cooperating third party, 
and a preboot application manager (PAM) portion. After 2^""°™' deVel ° P and msX f P 1 ^" the 
shadowing to RAM, the PAM portion is called and executed Flash R ™ «>«Ptod for a wide variety of purposes. In one 
prior to loading the OS, and causes one or more applications «SPect and embodiment of the invention phig-ms may be 
to be executed before OS loading is initiated, and wherein, pre , pareda ° d pr0Vlded 10 °™ S by the BIOS manufacturer > 
at OS boot, the BIOS represents the extent of its address 45 and an OEM may then install the appropriate mix of plug-ins 
space in RAM to include the one or more applications, for a kooWD or ex P ected s y stem ^hitecture. 
thereby enabling the one or more applications to continue to 1° another aspect of the invention third parties may be 
execute during OS boot. The BIOS may be implemented as licensed or otherwise authorized to use a VROM develop- 
a virtual random access memory (VROM) BIOS in flash ment application provided by the BIOS manufacturer to 
memory. In embodiments of the present invention, for the 50 develop and provide to the marketplace new VROM plug- 
first time, it is possible to call and execute an application, ins. In some aspects end users may be able to also purchase 
such as a telephony application, very quickly after power on, and install plug- ins, such as by downloading from the 
and the application may continue to execute and be available Internet, for example. 

to a user while the operating system boots, and even after the In a preferred embodiment of the present invention the 

operating system is booted. 55 process of preparing and installing VROM-compatible plug- 

Borcc r^cci-DTTrrrnvT nu -rue no awtwp ins in a VROM BIOS works generally as follows: First a 

BRIEF DESCRIPTION OF THE DRAWING dcve laper, ^ a development applicatioilj pre . 

pares a plug-in incorporating the functional code to be 

FIG. 1 is an enhanced BIOS memory map of a com- installed. The functional code is accompanied by installation 

pressed BIOS in a 2 Mb Flask ROM according to an 60 co de compatible with the VROM-DVR of the VROM BIOS, 

embodiment of the present invention. \ n a system to which this plug-in is to be installed, the 

FIG. 2 illustrates the BIOS code map of FIG. 1 decom- VROM BIOS is copied to RAM. This is a physical copy of 

pressed and shadowed to RAM in an embodiment of the the ROM chip arrangement of code, not the shadowing that 

present invention. takes place when a BIOS is initiated. The installation code 

FIG. 3 is a block diagram illustrating the software archi- 65 accompanying the plug- in calls the VROM-DVR, which 

tecture of a VROM system according to an embodiment of manages the addition of the function code of the new plug-in 

the present invention. to the VROM BIOS copy in RAM. 
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In the installation process the VROM-DVR performs 
several operations, including checking for adequate space in 
the BIOS map for installation. In some embodiments, if the 
space is not available, the user may be prompted for 
approval to delete one or more resident modules to create 5 
room for the new plug- in. In others access may simply be 
denied, with explanation. If there is adequate space, the 
VROM-DVR adds the functional code of the new plug-in to 
the VROM BIOS RAM map, and then calls a reflash 
sequence to flash -erase the existing code in the BIOS chip, 10 
and to then copy the new RAM map to the chip. 

It is not necessary that the developer or installer have any 
detailed knowledge of the chip itself, or of the mapping of 
VROM BIOS code on the chip. The VROM-DVR is specific 
to these facts and manages the installation according to 15 
necessity. 

The VROM-BIOS is also adapted to manage deletion of 
plug-ins from a VROM BIOS chip in a fashion similar to 
that described above for code additions. A compatible pro- 
gram can call the VROM-DVR an initiate deletion of one or 20 
more modules, after which the chip may be reflashed to a 
new form. Other functions of the VROM-DVR are described 
below. 

In many embodiments of the invention the VROM-DVR 
as a part of the VROM BIOS has other functionality, such as 
prioritizing and enabling plug-ins. The VROM-DVR may, 
for example, cooperate with POST code to scan for plug-ins, 
and enable and initiate plug- ins found. 

FIG. 1 is a VROM BIOS 100 memory map illustrated in 3Q 
a compressed state in a 2 Mb (512 KB) Flash ROM chip 
according to an embodiment of the present invention, 
wherein VROM BIOS 100 has been enhanced with a unique 
VROM-DVR 101. The 2 Mb ROM chip is not limiting to the 
invention, which is applicable to other sizes, but 2 Mb is 3S 
considered an adequate choice for illustrating aspects of the 
invention. 

As an analogy, VROM-DVR 101 may be thought of in 
some respects as acting something like a mini-operating 
system that would read and write to a hard drive on a 40 
computer, except that in this case it is adapted to read from 
and write to the flash memory in BIOS 100. This unique and 
innovative approach allows a third party, such as an OEM, 
to add or remove, components to and from BIOS 100 
without intimate knowledge of the architecture and code 45 
content and residence of BIOS 100. 

As described above, in a typical system ROM BIOS code 
is shadowed to RAM at startup. Since the code in the BIOS 
chip is compressed, decompression is typically accom- 
plished as the code is passed to RAM. FIG. 2 is a RAM map 50 
of BIOS code after decompression and transfer to RAM. The 
amount of memory for BIOS and associated code in. RAM 
is, of course, an issue, as memory is a precious resource in 
any system. The first set of operations to be performed by the 
BIOS code is the Power On Self Test (POST), and, after its 55 
use, this part of the code need not be retained in RAM, 
because it is not utilized during normal operations after 
POST, and will not be needed again until the system is 
powered down and restarted. 

Referring to FIG. 1 and FIG. 2, memory addresses of data 60 
blocks in this embodiment are shown to the right of each 
block, and will be familiar to those skilled in the art. 
VROM-DVR 101 written into BIOS 100 during manufac- 
turing provides a mechanism and method for prioritizing, 
enabling, disabling, adding, and deleting plug-ins without 65 
requiring intimate knowledge of chip architecture or code 
residence. The VROM-DVR is a code sequence that may be 
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accessed by a CPU and executed, and is specific to a 
VROM-BIOS and its Flash ROM, having structure and/or 
access to stored data specific to the VROM BIOS version 
and the specific chip upon which the VROM BIOS is stored, 
in this example a 2 Mb Flash ROM. 

Referring to FIG. 1, in addition to an 8 KB Boot Block, 
there is a 4 KB plug and play (PnP) utility, written in as 
extended system configuration data (ESCD), 4 KB of P6 
Micro-code (known in the art), a 4 KB code decompression 
and memory sizing sector, and a compressed BIOS sector 
comprising the compressed BIOS function code. Section 
103 is a 64 KB section reserved for plug-ins provided by an 
OEM, and section 105 is a 64 KB section reserved for add-in 
routines such as a Video Graphics Array (VGA) adapter, a 
small computer systems interface (SCSI) driver network and 
PC card plug-ins, and the like. 

FIG. 2 is an exemplary BIOS memory map of the BIOS 
code of FIG. 1 shadowed to RAM according to an embodi- 
ment of the present invention. In this instance, runtime 
routines, IBM compatible code, and system set up routines 
are shown. Address location in RAM is illustrated to the left 
of FIG. 2 as is known in the art. 64 KB of power on self test 
(POST) code is shown in the shadowed RAM, and this same 
sector is shown again as empty after booting as element 109. 
This POST code is no longer needed after boot. 

In the VROM BIOS the POST code is adapted to recog- 
nize added plug-ins and BIOS extensions, to relocate such 
plug-ins and extensions out of Flash ROM into shadow 
RAM, and to look for a signature and activate each such 
module by executing the module's INIT routine. 

Table 111 in FIG. 2 represents locations in RAM where 
add-in device modules in section 105 of FIG. 1 are shad- 
owed in this exemplary embodiment. The amount of add-in 
data or plug-n modules that may be employed is only limited 
by the amount of available unused flash -memory. 

FIG. 3 is a block diagram illustrating software architec- 
ture of a VROM BIOS system according to an embodiment 
of the present invention. An application layer 113 represents 
a user interface adapted to enable a third party to prepare 
plug-ins to be added to a VROM BIOS having a VROM- 
DVR according to the invention, and includes in this 
example a software development kit (SDK) and application 
program interface (API) library. Examples of add-in pro- 
grams may include but are not limited to virus protection 
programs, disk utility programs, network card scanning 
programs, and so on. 

VROM driver 115 is the driver on the Flash ROM chip in 
this example (VROM-DVR) and is adapted to access each 
VROM area on BIOS 100 of FIG. 1. VROM-DVR 115 is 
specific to a Flash ROM (or other non-volatile storage 
device) upon which it resides, to the VROM-BIOS inte- 
grated in the ROM, and also to the Operating System (OS) 
of a computer upon to which the VROM-BIOS will be 
applicable. VROM BIOS 119 is the code set on BIOS 100 
providing BIOS functionality. 

FIG. 4 is a table illustrating the structure of an Installation 
Check that allows application software to determine if a 
system has in fact a VROM BIOS according to an embodi- 
ment of the present invention. The Installation Check 
includes a searching method for a signature of the ASCII 
string "VROM BIOS" in system memory starting from 
OFOOOOh to OFFFFFh at every 16-byte boundary. The soft- 
ware can then determine if the structure is valid by calcu- 
lating the checksum. The method to perform the checksum 
operation is to add up the length bytes from the top of the 
structure into an 8-bit value. A sum of zero indicates a valid 
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structure. The entry points in this structure are the software 
interface to the VROM BIOS functions. 

FIG. 5 is a field definition table for the various fields listed 
in FIG. 4. Beginning at the top of FIG. 5, the field Signature 
is represented as an American Standard Code for Informa- 
tion Exchange (ASCII) string which is a common method 
for representing text with symbols. For example the char- 
acter string "VROMBIOS" could be used. The version field 
is a BCD value that is represented as in the following 
example (value of 10h=version 1.0) etc. Length field is the 
total bytes of the whole installation structure starting from 
the signature. Checksum field is a simple error detection 
scheme that is known in the art. Checksum adds up the bytes 
in an installation structure and a receiving station then 
compares values to verify a valid structure. Real Mode 
Interface is the segment offset to the entry point. Real mode 
is the mode in which DOS executes it's programs. 32-bit 
protected mode interface is a code segment base address. 
With protected mode memory space is protected from over- 
lapping into another memory space assigned to a different 
program. The Windows__ operating system uses protected 
mode. 

By incorporating both Real Mode and Protected Mode, 
add-in programs may be installed from DOS and from 
Windows_. It will be apparent to one with skill in the art 
that there are variations possible with respect to the tables 
presented in FIGS. 4 and 5 without departing from the spirit 
and scope of the present invention. For example, in one 
embodiment, installation could be performed using a differ- 
ent platform such as O/S 2 or UNIX. In a preferred embodi- 
ment a Windows_ environment is utilized. 

FIG. 6 is a table illustrating third party software function 
according to an embodiment of the present invention 
wherein listed functions are options to a third party such as 
a system integrator or a PC user. From top down, Function-0 
Get VROM Lists returns VROM lists residing in flash 
VROM into a List Buffer where they can be analyzed. List 
Buffer as termed by the inventor must be large enough to 
hold all of the VROM lists. The next function is Function- 1 
Get VROM Size which returns the VROM size in bytes to 
the calling software. Function-2 Enable/Disable VROM List 
allows the caller to enable or disable the VROM List in the 
VROM lists. The VROM buffer as termed by the inventor 
must be large enough to store all of the VROM data. 
Function-3 Read in VROM Data allows a third party calling 
software to read in VROM data from VROM List area. 
Function-4 Add/Delete VROM Data allows third party call- 
ing software to add or delete VROM data. 

It will be apparent to one with skill in the art that a third 
party calling software may be utilized by a software vendor 
that is licensed to provide the BIOS add-in program, a 
licensed system integrator, or by a user that has purchased a 
BIOS add-in program. Termed "VROM plug-ins" by the 
inventor, these add-in programs will typically be licensed 
products and can be either pre-boot functions or post-boot, 
BIOS-enabled functions. 

FIG. 7 is a table illustrating a VROM List structure and an 
accompanying definition table according to an embodiment 
of the present invention. The inventor fully expects the list 
structure and accompanying definitions to be self- 
explanatory to those with skill in the art. 

The VROM List tells the calling software application 
important information regarding where data is stored, how 
large each data block is, the type of data such as VGA, and 
so on. This data will change to reflect current status after an 
installation and/or deletion of a program. A mechanism (not 
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shown) is also provided to offer a set of instructions in the 
event of a return error indicating a problem with the install. 
In one embodiment, a protection mechanism may restore 
previous settings by using a mirroring technique (known in 
5 the art) so that a backup or default installation may take 
priority. 

It will be apparent to one with skill in the art that there are 
a variety of alterations that might be made in the embodi- 
ments of the invention described herein without departing 

to from the spirit and scope of the present invention. Some of 
these variations have already been discussed, such as the use 
of other non-volatile storage devices other than Flash ROM, 
and differing sized of storage devices that may be used other 
than the 2 Mb ROM described in embodiments herein. There 

15 are many other such variations. It is well-known, for 
example, that programmers have individualistic ways to 
structure code, and many variable code structures may 
accomplish similar ends. Similarly there are many sorts of 
plug-ins that may be accomplished to a VROM BIOS 

20 according to an embodiment of the present invention. Some 
may accomplish pre-boot functions, and others may accom- 
plish post-boot BIOS-enabled functions. Among the many 
possibilities are disk utility programs, virus protection 
programs, PC card scanning programs, specific device BIOS 

25 code, and the like. 

Pre-boot Application Manager (PAM) 

In one aspect of the present invention a BIOS extension 
module is provided and adapted to locate, initialize, and 
execute certain applications, including multimedia applica- 

30 tions in a preferred embodiment, from stored location on a 
hard drive or other connected mass-storage-device (MSD) 
before normal booting of the operating system. The exten- 
sion module, termed a pre-boot application-manager (PAM) 
by the inventors, may be provided as part of a normal BIOS, 

35 or as part of a V-ROM BIOS described in the disclosure 
referenced above as a parent application and incorporated 
herein by reference. 

In a preferred embodiment, a V-ROM BIOS as known to 
the inventors is used because of versatile flash-in capabilities 

40 inherent to the device. A PAM in embodiments of the present 
invention is a software module installed or flashed in as an 
extension to a system BIOS such as a V-ROM BIOS. A PAM 
module in this embodiment comprises separate parts that 
take up residence in specific areas of V-ROM-BIOS. For 

45 example, a NVM part of PAM is resident in NVM (non- 
volatile-memory) and is loaded and executed by V-ROM. A 
post-boot part of PAM is implemented for accessing or 
setting up new MSDs, finds required driver information 
(location and type), and binds that information into a third 

50 part or file-system-structure (FSS) module, which then 
becomes a part of NVM resident code. One with skill in the 
art will appreciate that the functional implementation of a 
PAM into a BIOS chip, whether flashed in, or pre -installed, 
will follow BIOS convention during execution such as 

55 compression, shadowing, and addressing techniques that 
have already been described with reference to FIGS. 1-7 
above. Therefore, the inventors deem that the process steps 
described below will be sufficient for explaining the present 
invention in an enabling manner, 

60 FIG. 8 is a process flow chart illustrating logical process 
steps for V-ROM execution of a PAM according to an 
embodiment of the present invention. In this exemplary 
embodiment, the method and apparatus of the present inven- 
tion is provided and integrated with V-ROM functions as 

65 described above. This process assumes that a flash able 
V-ROM chip is installed and operable according to previous 
embodiments as taught in disclosure above. 
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la step 121, pre -boot BIOS operation begins. In step 123, 
V-ROM calls and executes a PAM module. Step 133 rep- 
resents a pre-boot mode during which time PAM begins 
operation. At step 135, PAM accesses and scans it's FSS 
module for valid MSD information such as type, size, OS 
parameters, and so on. If MSD information pointers are 
available, indicating that a device is recognized, then the 
designated MSD is analyzed in step 137. This step confirms 
parameters for a match such as type (SCSI, IDE), size, 
(capacity, available memory), format (number of boot 
partitions, type of OS), and so on. At step 139, PAM 
determines if a match has been made. If yes, the process 
resumes with steps illustrated in FIG. 9, step 140. However, 
if there is no match, then it is assumed that the system has 
been modified (given different instruction) or the MSD is a 
new device and has to be re-set. 

Assuming for purpose of description that the system is 
being booted for the first time after flash-in, or that a new 
default MSD is being added, there would be no match in step 
139. At this juncture, PAM sets a flag (step 141) which may 
be a simple binary code so that new parameters associated 
with the new MSD may be loaded into BIOS for the next 
boot operation. Such parameters may include any required 
information including but not limited to driver location and 
identification for accessing and launching any pre-boot 
applications such as videos, static ads, audio ads, or other 
pre-boot informative displays. The process then proceeds as 
illustrated via directional arrow back to step 125 to boot the 
OS. 

After OS booting initiated in step 125, an FSS driver 
having capability of accessing and analyzing a connected 
MSD is activated in step 127, along with other system 
drivers. At step 129, the driver checks for the pre -set flag set 
in step 141. If the flag is found, which means that there is 
currently no valid MSD installed, the process proceeds to 
step 143 where the new MSD is analyzed. At step 145, the 
parameters associated with MSD drivers and other drivers 
that are generic to pre-boot applications intended to be 
executed during pre-boot operations, are located on the 
MSD. At step 147, such parameters are loaded and prepared 
for transfer into the FSS module of step 135. After comple- 
tion of transfer of parameters from the MSD into the FSS 
module at step 149, normal system operation, including 
complete booting of the OS resumes in step 151. 

The next time that the system is powered on, the new 
changes are recognized during pre-boot analysis and any 
loaded ads including multimedia ads will be accessed and 
displayed automatically, after which the OS will be booted. 
If however, there is no flag set in step 141, then there will be 
no flag found in step 129. This assumes that required 
information was already accessed, loaded and matched in 
step 139 during a previous boot event. If so, then the process 
proceeds to FIG. 9 as previously described. 

FIG. 9 is a process flow chart depended from the flow 
chart of FIG. 8 illustrating an application loading sequence 
according to an embodiment of the present invention. FIG. 
9 illustrates the loading sequence for accessing an MSD and 
displaying such as advertisements according to matched 
information contained in the FSS module of step 139 (FIG. 
8). In step 140, the FSS module accesses and loads MSD 
drivers into NVM. In step 142 any application drivers are 
similarly loaded. At step 144, any targeted application 
programs (ads) are loaded from the MSD. The loaded 
applications) is then executed in step 146. The application's 
driver is then executed in step 148 in a manner consistent 
with normal execution under a fully loaded OS. The 
applications) is displayed during the time from power-on to 
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OS-load, (pre-boot and possibly during-boot). A new flag is 
then set at step 150 which will point to any new additions or 
changes to the pre-boot advertisements for the next boot-up. 
The process flow sequence as taught above in FIGS. 8 and 

5 9 is meant to be exemplary of one such process that could 
be implemented in practice of the present invention. There 
are many variations that may be included without departing 
from the spirit and scope of the present invention. In one 
embodiment for example, an ad schedule may be down- 

10 loaded from a switched packet network to an MSD. The ad 
schedule may include several individual ads, such as per- 
haps MPEG video clips, wherein one clip will be played per 
pre-boot event in serial order (rotated). An FSS driver 
capable of disseminating the ad schedule, and identifying 

15 the appropriate ad and application driver will set a new flag 
for the next ad after playing the previous ad. In this way, the 
next time the system is powered on, the new ad will be 
loaded and played. 

In another embodiment of the present invention, an appli- 

20 cation is provided as part of PAM software that resides on 
a connected MSD and can communicate with counterpart 
software in system BIOS. In this embodiment, any new ads 
of any media type may be selected by a user and flashed into 
BIOS at any time during normal operation. Similarly, such 

25 ads and driver information may be flashed into BIOS by a 
third party utilizing a connected network server adapted for 
the purpose. After the system is powered on, the new 
pointers are registered and retained into system BIOS (FSS 
module). These pointers may indicate, in some 

30 embodiments, a new or alternately selected MSD device on 
which the ads reside. 

In still another embodiment, an FSS module may be 
segmented to contain separate blocks of information per- 
taining to more than one MSD having separate ads resident 

35 thereon. This variation may reflect a number of individual 
video-display-units (VDU's) networked together and having 
minimal and individual MSD capability. A main booting 
station and MSD connected to the network of VDU's may 
provide BIOS initialization for each connected unit. In this 

40 embodiment, pre-boot ads or instruction may be personal- 
ized to individuals assigned such VDU's. 

FIG. 10 is a block diagram depicting how a pre-boot 
application may be loaded and enabled to execute before the 
operating system loads, during the time the operating system 

45 loads, and to be registered and used after the operating 
system has booted. 

In FIG. 10 element 151 represents the Flash VROM 
described above, wherein the BIOS code is shadowed (arrow 
155) to upper addresses of random access memory (RAM) 

50 153 as is typical in the art. In alternative embodiments the 
Flash VROM shown could be BIOS ROM of other sorts as 
well. After the BIOS code is operable in RAM, the BIOS 
loads a pre-boot application as described above, from either 
the code previously shadowed to RAM in this example or 

55 from a mass storage device (MSD) 159, as illustrated by 
arrow 161 and also previously described in other embodi- 
ments above. 

In this embodiment a step is taken beyond the steps to 
enable a pre-boot application in previous examples. That 

60 step is that the BIOS represents both its own address space 
and that of the pre-boot application as part of the BIOS, so 
the OS will not overwrite either during boot. This may be 
done in different ways depending on the operating system, 
which are generally well known. 

65 By this process, the pre-boot application may continue to 
operate during the time the OS loads, indicated by arrow 
163. In some cases it may operate beyond that point, but to 
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assure a stable system is presented for operation, another 
step is needed. 

The further step activates at the time the OS finishes 
loading. At this point in time in this embodiment a special 
driver, previously included in the OS configuration, is 
executed. This driver then either relocates the application to 
within the OS, or binds the application into the OS con- 
trolled space by "freeing" the resources for the OS, but using 
them at the same time. In Windows 98™ for example, the 
driver could use the conventions of the virtual address 
descriptor (VAD) in conjunction with the virtual memory 
manager (VMM) to mark the extent of the "recovered" 
space. 

Although the process itself seems very complicated when 
compared to a conventional boot operation followed by an 
immediate launch of a desired application, real-time issues 
have to be considered to understand the advantages of the 
unique system provided by this embodiment of the inven- 
tion. Even though an OS boot takes only 30-90 seconds, in 
some situations that may be an unacceptable length of time 
to wait for an application to be launched. For example if the 
user must make an emergency phone call using the computer 
system to be booted, he or she may have to wait 90 seconds 
in a conventional system. In a system according to the 
embodiment presented here, the pre-boot phase may be in 
the milliseconds or in the low seconds if an MSD such as a 
hard disk is used. 

The embodiment described above teaches a method for 
loading one application to execute before, during and after 
OS boot. It will be apparent to one with skill in the art that 
the method may be extended to load and execute more than 
one such application. For example, one may configure a 
VROM or other BIOS to load both an address book, and an 
IP telephony application enabling IP telephone calls. One 
might also include an e-mail client. There are many such 
possibilities, and communication applications are clearly 
desirable candidates. There are, of course, other possibili- 
ties. For example, a writer may wish to go directly to a word 
processor. 

There are many variant possibilities for presenting pre- 
boot applications. Therefore, the method and apparatus of 
the present invention should be afforded the broadest scope. 
The spirit and scope of the present invention is limited only 
by the claims that follow. 

What is claimed is: 

1. A method for calling an application on a computer 
before booting an operating system (OS), and continuing to 
execute the application during OS boot, the method com- 
prising: 

(a) including a preboot application manager (PAM) soft- 
ware in a BIOS directing computer initialization and 
the OS boot; 

(b) calling and executing the PAM upon startup prior to 
OS boot; 

(c) checking a file system structure (FSS) in the BIOS by 
the PAM for pointers to the application; 

(d) loading the application to a RAM and executing the 
application under the control of the computer; 

(e) presenting, at OS boot, an address extent of a protected 
memory region as including the application; and 

(f) continuing to execute the application during OS boot. 
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2. The method of claim 1 further comprising a step for 
calling a special driver after OS boot to register the appli- 
cation and include it in the OS configuration, thereby 
enabling the application to execute in a stable manner after 

5 OS boot. 

3. The method of claim 1 wherein the PAM is a part of a 
configurable virtual random access memory BIOS (VROM 
BIOS) implemented in flash memory. 

4. The method of claim 1, wherein presenting, at OS boot, 
an address extent of a protected memory region comprises 
representing to the OS that an address space of the appli- 
cation is part of the BIOS, and wherein, in response, the OS 
will not overwrite said address space during OS boot. 

5. The method of claim 1, further comprising loading, 
using the FSS, a driver for said mass storage into a non- 
volatile memory of said computer. 

6. The method of claim 1, further comprising presenting, 
by the application, content to a user during said OS boot. 

7. The method of claim 1, further comprising accessing 
said mass storage, by said PAM, after said OS boot. 

8. The method of claim 1, further comprising detecting a 
flag* by said FSS, said flag to indicate that a new mass 
storage has not been configured, and loading parameters for 
said new mass storage into said FSS. 

25 9. A computer system, comprising: 

a pre-boot application manager (PAM) in a BIOS of the 
computer system for directing computer initialization 
and an operating system (OS) boot; 
a random access memory (RAM); and 
30 an operating system (OS); 

wherein the BIOS is shadowed to the RAM at power-on 
or reset, the PAM executes to check a file system 
structure (FSS) in the BIOS for a pointer to an 
application, upon finding the application the applica- 
35 tion is loaded to the RAM and executed under the 
control of the computer system, and at the OS boot, the 
BIOS represents a BIOS space in RAM to the OS as 
including a space of the application. 

10. The computer system of claim 9 further comprising a 
40 special driver called after OS boot to register the application 

and include it in the OS configuration, thereby enabling the 
application to execute in a stable manner after OS boot. 

11. The computer system of claim 9 wherein the PAM is 
a part of a configurable virtual random access memory BIOS 

45 (VROM BIOS) implemented in flash memory. 

12. A basic input-output system (BIOS), comprising: 

a BIOS code portion for initializing a computer system 

and loading an operating system (OS); and 
a preboot application manager (PAM) portion; 

50 wherein, after shadowing to a RAM, the PAM portion is 
called and executed prior to loading the OS, and causes 
one or more applications to be executed under the 
control of the computer system before loading the OS, 
and wherein, at an OS boot, the BIOS represents the 

55 extent of its address space in the RAM to include the 
one or more applications, thereby enabling the one or 
more applications to continue to execute during OS 
boot. 

13. The BIOS of claim 12 implemented as a virtual 
60 random access memory (VROM) BIOS in flash memory. 

***** 
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